The present invention relates generally to data processing systems, and more specifically, to operating local caches for a shared storage device in a storage area network (SAN).
Compared with traditional hard disks, flash/solid state devices (SSD) have superior input/output (I/O) performance. In addition, the cost of SSD devices has been continuously decreasing. These two factors make it increasingly popular to use SSD devices as a so called “second-level” cache which resides between the main memory (e.g., random access memory or RAM) and a primary persistent storage such as a hard disk (as opposed to so called “first-level” or buffer cache which needs to utilize a portion of the main memory). Such a “second level” cache can be used by an operating system (OS) to cache “hot” I/O blocks (e.g., I/O blocks that may be frequently accessed) to improve I/O latency and throughput. Typically, such second-level caching involves a filter driver in the OS kernel I/O stack, which can intercept all I/Os, identify hot blocks, and dispatch I/Os to a cache or persistent storage.
In a virtualized environment, however, using a SSD device as a second-level cache brings up new challenges. For example, because a host computer system (e.g., a “host”) supports the running of multiple virtual machines (VMs) in a virtualization environment, the host computer system would need to manage the second-level cache on a per-VM basis and maintain VM-specific caching policies. In addition, VM live migration, also referred to as “VMotion”, is a technology that enables moving running VMs between different hosts without service interruption, and with complete transaction integrity. During VMotion, the hypervisor moves a VM's memory to the new host over a network connection (such as Ethernet) first, and then quickly suspends the VM on the original host and resumes it on the new host. It is often critical to keep the migration latency low in order to guarantee continuous service availability for VMotion.